home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 1998 November / IRIX 6.5.2 Base Documentation November 1998.img / usr / share / catman / u_man / cat1 / co.z / co
Text File  |  1998-10-20  |  23KB  |  397 lines
  1.  
  2.  
  3.  
  4. CCCCOOOO((((1111))))                                                                    CCCCOOOO((((1111))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      co - check out RCS revisions
  10.  
  11. SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.      ccccoooo [_o_p_t_i_o_n_s] _f_i_l_e ...
  13.  
  14. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  15.      ccccoooo retrieves a revision from each RCS file and stores it into the
  16.      corresponding working file.
  17.  
  18.      Pathnames matching an RCS suffix denote RCS files; all others denote
  19.      working files.  Names are paired as explained in cccciiii(1).
  20.  
  21.      Revisions of an RCS file may be checked out locked or unlocked.  Locking
  22.      a revision prevents overlapping updates.  A revision checked out for
  23.      reading or processing (e.g., compiling) need not be locked.  A revision
  24.      checked out for editing and later checkin must normally be locked.
  25.      Checkout with locking fails if the revision to be checked out is
  26.      currently locked by another user.  (A lock may be broken with rrrrccccssss(1).)
  27.      Checkout with locking also requires the caller to be on the access list
  28.      of the RCS file, unless he is the owner of the file or the superuser, or
  29.      the access list is empty.  Checkout without locking is not subject to
  30.      accesslist restrictions, and is not affected by the presence of locks.
  31.  
  32.      A revision is selected by options for revision or branch number, checkin
  33.      date/time, author, or state.  When the selection options are applied in
  34.      combination, ccccoooo retrieves the latest revision that satisfies all of them.
  35.      If none of the selection options is specified, ccccoooo retrieves the latest
  36.      revision on the default branch (normally the trunk, see the ----bbbb option of
  37.      rrrrccccssss(1)).  A revision or branch number may be attached to any of the
  38.      options ----ffff, ----IIII, ----llll, ----MMMM, ----pppp, ----qqqq, ----rrrr, or ----uuuu.  The options ----dddd (date), ----ssss
  39.      (state), and ----wwww (author) retrieve from a single branch, the _s_e_l_e_c_t_e_d
  40.      branch, which is either specified by one of ----ffff, ..., ----uuuu, or the default
  41.      branch.
  42.  
  43.      A ccccoooo command applied to an RCS file with no revisions creates a zero-
  44.      length working file.  ccccoooo always performs keyword substitution (see
  45.      below).
  46.  
  47. OOOOPPPPTTTTIIIIOOOONNNNSSSS
  48.      ----rrrr[_r_e_v]
  49.           retrieves the latest revision whose number is less than or equal to
  50.           _r_e_v.  If _r_e_v indicates a branch rather than a revision, the latest
  51.           revision on that branch is retrieved.  If _r_e_v is omitted, the latest
  52.           revision on the default branch (see the ----bbbb option of rrrrccccssss(1)) is
  53.           retrieved.  If _r_e_v is $$$$, ccccoooo determines the revision number from
  54.           keyword values in the working file.  Otherwise, a revision is
  55.           composed of one or more numeric or symbolic fields separated by
  56.           periods.  If _r_e_v begins with a period, then the default branch
  57.           (normally the trunk) is prepended to it.  If _r_e_v is a branch number
  58.           followed by a period, then the latest revision on that branch is
  59.           used.  The numeric equivalent of a symbolic field is specified with
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. CCCCOOOO((((1111))))                                                                    CCCCOOOO((((1111))))
  71.  
  72.  
  73.  
  74.           the ----nnnn option of the commands cccciiii(1) and rrrrccccssss(1).
  75.  
  76.      ----llll[_r_e_v]
  77.           same as ----rrrr, except that it also locks the retrieved revision for the
  78.           caller.
  79.  
  80.      ----uuuu[_r_e_v]
  81.           same as ----rrrr, except that it unlocks the retrieved revision if it was
  82.           locked by the caller.  If _r_e_v is omitted, ----uuuu retrieves the revision
  83.           locked by the caller, if there is one; otherwise, it retrieves the
  84.           latest revision on the default branch.
  85.  
  86.      ----ffff[_r_e_v]
  87.           forces the overwriting of the working file; useful in connection
  88.           with ----qqqq.  See also FILE MODES below.
  89.  
  90.      ----kkkkkkkkvvvv Generate keyword strings using the default form, e.g. $$$$RRRReeeevvvviiiissssiiiioooonnnn::::
  91.           1111....11114444 $$$$ for the RRRReeeevvvviiiissssiiiioooonnnn keyword.  A locker's name is inserted in the
  92.           value of the HHHHeeeeaaaaddddeeeerrrr, IIIIdddd, and LLLLoooocccckkkkeeeerrrr keyword strings only as a file
  93.           is being locked, i.e. by cccciiii ----llll and ccccoooo ----llll.  This is the default.
  94.  
  95.      ----kkkkkkkkvvvvllll
  96.           Like ----kkkkkkkkvvvv, except that a locker's name is always inserted if the
  97.           given revision is currently locked.
  98.  
  99.      ----kkkkkkkk  Generate only keyword names in keyword strings; omit their values.
  100.           See KEYWORD SUBSTITUTION below.  For example, for the RRRReeeevvvviiiissssiiiioooonnnn
  101.           keyword, generate the string $$$$RRRReeeevvvviiiissssiiiioooonnnn$$$$ instead of $$$$RRRReeeevvvviiiissssiiiioooonnnn:::: 1111....11114444
  102.           $$$$.  This option is useful to ignore differences due to keyword
  103.           substitution when comparing different revisions of a file.  Log
  104.           messages are inserted after $$$$LLLLoooogggg$$$$ keywords even if ----kkkkkkkk is specified,
  105.           since this tends to be more useful when merging changes.
  106.  
  107.      ----kkkkoooo  Generate the old keyword string, present in the working file just
  108.           before it was checked in.  For example, for the RRRReeeevvvviiiissssiiiioooonnnn keyword,
  109.           generate the string $$$$RRRReeeevvvviiiissssiiiioooonnnn:::: 1111....1111 $$$$ instead of $$$$RRRReeeevvvviiiissssiiiioooonnnn:::: 1111....11114444 $$$$ if
  110.           that is how the string appeared when the file was checked in.  This
  111.           can be useful for file formats that cannot tolerate any changes to
  112.           substrings that happen to take the form of keyword strings.
  113.  
  114.      ----kkkkbbbb  Generate a binary image of the old keyword string.  This acts like
  115.           ----kkkkoooo, except it performs all working file input and output in binary
  116.           mode.  This makes little difference on Posix and Unix hosts, but on
  117.           DOS-like hosts one should use rrrrccccssss ----iiii ----kkkkbbbb to initialize an RCS file
  118.           intended to be used for binary files.  Also, on all hosts,
  119.           rrrrccccssssmmmmeeeerrrrggggeeee(1) normally refuses to merge files when ----kkkkbbbb is in effect.
  120.  
  121.      ----kkkkvvvv  Generate only keyword values for keyword strings.  For example, for
  122.           the RRRReeeevvvviiiissssiiiioooonnnn keyword, generate the string 1111....11114444 instead of $$$$RRRReeeevvvviiiissssiiiioooonnnn::::
  123.           1111....11114444 $$$$.  This can help generate files in programming languages where
  124.           it is hard to strip keyword delimiters like $$$$RRRReeeevvvviiiissssiiiioooonnnn:::: $$$$ from a
  125.           string.  However, further keyword substitution cannot be performed
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. CCCCOOOO((((1111))))                                                                    CCCCOOOO((((1111))))
  137.  
  138.  
  139.  
  140.           once the keyword names are removed, so this option should be used
  141.           with care.  Because of this danger of losing keywords, this option
  142.           cannot be combined with ----llll, and the owner write permission of the
  143.           working file is turned off; to edit the file later, check it out
  144.           again without ----kkkkvvvv.
  145.  
  146.      ----pppp[_r_e_v]
  147.           prints the retrieved revision on the standard output rather than
  148.           storing it in the working file.  This option is useful when ccccoooo is
  149.           part of a pipe.
  150.  
  151.      ----qqqq[_r_e_v]
  152.           quiet mode; diagnostics are not printed.
  153.  
  154.      ----IIII[_r_e_v]
  155.           interactive mode; the user is prompted and questioned even if the
  156.           standard input is not a terminal.
  157.  
  158.      ----dddd_d_a_t_e
  159.           retrieves the latest revision on the selected branch whose checkin
  160.           date/time is less than or equal to _d_a_t_e.  The date and time may be
  161.           given in free format.  The time zone LLLLTTTT stands for local time; other
  162.           common time zone names are understood.  For example, the following
  163.           _d_a_t_es are equivalent if local time is January 11, 1990, 8pm Pacific
  164.           Standard Time, eight hours west of Coordinated Universal Time (UTC):
  165.  
  166.                8888::::00000000 ppppmmmm lllltttt
  167.                4444::::00000000 AAAAMMMM,,,, JJJJaaaannnn.... 11112222,,,, 1111999999990000           default is UTC
  168.                1111999999990000----00001111----11112222 00004444::::00000000::::00000000++++00000000           ISO 8601 (UTC)
  169.                1111999999990000----00001111----11111111 22220000::::00000000::::00000000----00008888           ISO 8601 (local time)
  170.                1111999999990000////00001111////11112222 00004444::::00000000::::00000000              traditional RCS format
  171.                TTTThhhhuuuu JJJJaaaannnn 11111111 22220000::::00000000::::00000000 1111999999990000 LLLLTTTT      output of ccccttttiiiimmmmeeee(3) + LLLLTTTT
  172.                TTTThhhhuuuu JJJJaaaannnn 11111111 22220000::::00000000::::00000000 PPPPSSSSTTTT 1111999999990000     output of ddddaaaatttteeee(1)
  173.                FFFFrrrriiii JJJJaaaannnn 11112222 00004444::::00000000::::00000000 GGGGMMMMTTTT 1111999999990000
  174.                TTTThhhhuuuu,,,, 11111111 JJJJaaaannnn 1111999999990000 22220000::::00000000::::00000000 ----0000888800000000  Internet RFC 822
  175.                11112222----JJJJaaaannnnuuuuaaaarrrryyyy----1111999999990000,,,, 00004444::::00000000 WWWWEEEETTTT
  176.  
  177.           Most fields in the date and time can be defaulted.  The default time
  178.           zone is normally UTC, but this can be overridden by the ----zzzz option.
  179.           The other defaults are determined in the order year, month, day,
  180.           hour, minute, and second (most to least significant).  At least one
  181.           of these fields must be provided.  For omitted fields that are of
  182.           higher significance than the highest provided field, the time zone's
  183.           current values are assumed.  For all other omitted fields, the
  184.           lowest possible values are assumed.  For example, without ----zzzz, the
  185.           date 22220000,,,, 11110000::::33330000 defaults to 10:30:00 UTC of the 20th of the UTC time
  186.           zone's current month and year.  The date/time must be quoted if it
  187.           contains spaces.
  188.  
  189.      ----MMMM[_r_e_v]
  190.           Set the modification time on the new working file to be the date of
  191.           the retrieved revision.  Use this option with care; it can confuse
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. CCCCOOOO((((1111))))                                                                    CCCCOOOO((((1111))))
  203.  
  204.  
  205.  
  206.           mmmmaaaakkkkeeee(1).
  207.  
  208.      ----ssss_s_t_a_t_e
  209.           retrieves the latest revision on the selected branch whose state is
  210.           set to _s_t_a_t_e.
  211.  
  212.      ----TTTT   Preserve the modification time on the RCS file even if the RCS file
  213.           changes because a lock is added or removed.  This option can
  214.           suppress extensive recompilation caused by a mmmmaaaakkkkeeee(1) dependency of
  215.           some other copy of the working file on the RCS file.  Use this
  216.           option with care; it can suppress recompilation even when it is
  217.           needed, i.e. when the change of lock would mean a change to keyword
  218.           strings in the other working file.
  219.  
  220.      ----wwww[_l_o_g_i_n]
  221.           retrieves the latest revision on the selected branch which was
  222.           checked in by the user with login name _l_o_g_i_n.  If the argument _l_o_g_i_n
  223.           is omitted, the caller's login is assumed.
  224.  
  225.      ----jjjj_j_o_i_n_l_i_s_t
  226.           generates a new revision which is the join of the revisions on
  227.           _j_o_i_n_l_i_s_t.  This option is largely obsoleted by rrrrccccssssmmmmeeeerrrrggggeeee(1) but is
  228.           retained for backwards compatibility.
  229.  
  230.           The _j_o_i_n_l_i_s_t is a comma-separated list of pairs of the form
  231.           _r_e_v_2::::_r_e_v_3, where _r_e_v_2 and _r_e_v_3 are (symbolic or numeric) revision
  232.           numbers.  For the initial such pair, _r_e_v_1 denotes the revision
  233.           selected by the above options ----ffff, ..., ----wwww.  For all other pairs,
  234.           _r_e_v_1 denotes the revision generated by the previous pair.  (Thus,
  235.           the output of one join becomes the input to the next.)
  236.  
  237.           For each pair, ccccoooo joins revisions _r_e_v_1 and _r_e_v_3 with respect to
  238.           _r_e_v_2.  This means that all changes that transform _r_e_v_2 into _r_e_v_1 are
  239.           applied to a copy of _r_e_v_3.  This is particularly useful if _r_e_v_1 and
  240.           _r_e_v_3 are the ends of two branches that have _r_e_v_2 as a common
  241.           ancestor.  If _r_e_v_1<_r_e_v_2<_r_e_v_3 on the same branch, joining generates a
  242.           new revision which is like _r_e_v_3, but with all changes that lead from
  243.           _r_e_v_1 to _r_e_v_2 undone.  If changes from _r_e_v_2 to _r_e_v_1 overlap with
  244.           changes from _r_e_v_2 to _r_e_v_3, ccccoooo reports overlaps as described in
  245.           mmmmeeeerrrrggggeeee(1).
  246.  
  247.           For the initial pair, _r_e_v_2 may be omitted.  The default is the
  248.           common ancestor.  If any of the arguments indicate branches, the
  249.           latest revisions on those branches are assumed.  The options ----llll and
  250.           ----uuuu lock or unlock _r_e_v_1.
  251.  
  252.      ----VVVV   Print RCS's version number.
  253.  
  254.      ----VVVV_n  Emulate RCS version _n, where _n may be 3333, 4444, or 5555.  This may be
  255.           useful when interchanging RCS files with others who are running
  256.           older versions of RCS.  To see which version of RCS your
  257.           correspondents are running, have them invoke rrrrccccssss ----VVVV; this works with
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. CCCCOOOO((((1111))))                                                                    CCCCOOOO((((1111))))
  269.  
  270.  
  271.  
  272.           newer versions of RCS.  If it doesn't work, have them invoke rrrrlllloooogggg on
  273.           an RCS file; if none of the first few lines of output contain the
  274.           string bbbbrrrraaaannnncccchhhh:::: it is version 3; if the dates' years have just two
  275.           digits, it is version 4; otherwise, it is version 5.  An RCS file
  276.           generated while emulating version 3 will lose its default branch.
  277.           An RCS revision generated while emulating version 4 or earlier will
  278.           have a timestamp that is off by up to 13 hours.  A revision
  279.           extracted while emulating version 4 or earlier will contain
  280.           abbreviated dates of the form _y_y////_m_m////_d_d instead of _y_y_y_y////_m_m////_d_d and may
  281.           also contain different white space in the substitution for $$$$LLLLoooogggg$$$$.
  282.  
  283.      ----xxxx_s_u_f_f_i_x_e_s
  284.           Use _s_u_f_f_i_x_e_s to characterize RCS files.  See cccciiii(1) for details.
  285.  
  286.      ----zzzz_z_o_n_e
  287.           specifies the date output format in keyword substitution, and
  288.           specifies the default time zone for _d_a_t_e in the ----dddd_d_a_t_e option.  The
  289.           _z_o_n_e should be empty, a numeric UTC offset, or the special string LLLLTTTT
  290.           for local time.  The default is an empty _z_o_n_e, which uses the
  291.           traditional RCS format of UTC without any time zone indication and
  292.           with slashes separating the parts of the date; otherwise, times are
  293.           output in ISO 8601 format with time zone indication.  For example,
  294.           if local time is January 11, 1990, 8pm Pacific Standard Time, eight
  295.           hours west of UTC, then the time is output as follows:
  296.  
  297.                _o_p_t_i_o_n    _t_i_m_e _o_u_t_p_u_t
  298.                ----zzzz        1111999999990000////00001111////11112222 00004444::::00000000::::00000000        (_d_e_f_a_u_l_t)
  299.                ----zzzzLLLLTTTT      1111999999990000----00001111----11111111 22220000::::00000000::::00000000----00008888
  300.                ----zzzz++++00005555::::33330000  1111999999990000----00001111----11112222 00009999::::33330000::::00000000++++00005555::::33330000
  301.  
  302.           The ----zzzz option does not affect dates stored in RCS files, which are
  303.           always UTC.
  304.  
  305. KKKKEEEEYYYYWWWWOOOORRRRDDDD SSSSUUUUBBBBSSSSTTTTIIIITTTTUUUUTTTTIIIIOOOONNNN
  306.      Strings of the form $$$$_k_e_y_w_o_r_d$$$$ and $$$$_k_e_y_w_o_r_d::::...$$$$ embedded in the text are
  307.      replaced with strings of the form $$$$_k_e_y_w_o_r_d::::_v_a_l_u_e$$$$ where _k_e_y_w_o_r_d and _v_a_l_u_e
  308.      are pairs listed below.  Keywords may be embedded in literal strings or
  309.      comments to identify a revision.
  310.  
  311.      Initially, the user enters strings of the form $$$$_k_e_y_w_o_r_d$$$$.  On checkout,
  312.      ccccoooo replaces these strings with strings of the form $$$$_k_e_y_w_o_r_d::::_v_a_l_u_e$$$$.  If a
  313.      revision containing strings of the latter form is checked back in, the
  314.      value fields will be replaced during the next checkout.  Thus, the
  315.      keyword values are automatically updated on checkout.  This automatic
  316.      substitution can be modified by the ----kkkk options.
  317.  
  318.      Keywords and their corresponding values:
  319.  
  320.      $$$$AAAAuuuutttthhhhoooorrrr$$$$
  321.           The login name of the user who checked in the revision.
  322.  
  323.  
  324.  
  325.  
  326.  
  327.                                                                         PPPPaaaaggggeeee 5555
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. CCCCOOOO((((1111))))                                                                    CCCCOOOO((((1111))))
  335.  
  336.  
  337.  
  338.      $$$$DDDDaaaatttteeee$$$$
  339.           The date and time the revision was checked in.  With ----zzzz_z_o_n_e a
  340.           numeric time zone offset is appended; otherwise, the date is UTC.
  341.  
  342.      $$$$HHHHeeeeaaaaddddeeeerrrr$$$$
  343.           A standard header containing the full pathname of the RCS file, the
  344.           revision number, the date and time, the author, the state, and the
  345.           locker (if locked).  With ----zzzz_z_o_n_e a numeric time zone offset is
  346.           appended to the date; otherwise, the date is UTC.
  347.  
  348.      $$$$IIIIdddd$$$$ Same as $$$$HHHHeeeeaaaaddddeeeerrrr$$$$, except that the RCS filename is without a path.
  349.  
  350.      $$$$LLLLoooocccckkkkeeeerrrr$$$$
  351.           The login name of the user who locked the revision (empty if not
  352.           locked).
  353.  
  354.      $$$$LLLLoooogggg$$$$
  355.           The log message supplied during checkin, preceded by a header
  356.           containing the RCS filename, the revision number, the author, and
  357.           the date and time.  With ----zzzz_z_o_n_e a numeric time zone offset is
  358.           appended; otherwise, the date is UTC.  Existing log messages are _n_o_t
  359.           replaced.  Instead, the new log message is inserted after $$$$LLLLoooogggg::::...$$$$.
  360.           This is useful for accumulating a complete change log in a source
  361.           file.
  362.  
  363.           Each inserted line is prefixed by the string that prefixes the $$$$LLLLoooogggg$$$$
  364.           line.  For example, if the $$$$LLLLoooogggg$$$$ line is  // $Log: tan.cc $ RCS
  365.           prefixes each line of the log with  // ....  This is useful for
  366.           languages with comments that go to the end of the line.  The
  367.           convention for other languages is to use a
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.                                                                         PPPPaaaaggggeeee 6666
  394.  
  395.  
  396.  
  397.